1. Field of the Invention
The present invention relates to the management of network transmission events handled by a multiprocessing system. More specifically, the invention relates to a highly scalable apparatus for managing termination of transmission transport via a plurality of transmit transport queues (TTQs).
2. Background of the Related Art
In the related art, operation in multiprocessing environments can handle tasks requiring a significant amount of computing power, which is best achieved by a plurality of processors operating in parallel. Over time, it has become easier in the related art to integrate more than one processing node on a single chip and thus create a more powerful related art parallel processing unit. While the foregoing related art parallel processing unit is highly effective in general processing applications, there exist other areas where it would be advantageous to employ multiprocessing, such as network processing.
In network processing, many events occur in parallel over short periods of time, and are generally independent of one another. For example, a file transfer protocol (FTP) session initiated by one user may be handled in parallel to another FTP session initiated by that same user or by another user. Also, other types of protocols may be handled in parallel.
In the above related art example, each FTP session generates its own events that follow FTP requirements, but are independent of each other. To achieve higher throughput for FTP in the related art system, these FTP sessions should be handled in parallel.
Network traffic is transported over the related art network using transmission control protocol (TCP) or user datagram protocol (UDP). TCP is used when a reliable transport medium is required, and is applied in the related art as described below.
TCP is a connection-oriented transport protocol that sends data as unstructured streams of bytes by sending a sequence of segments (i.e., a collection of data bytes sent as a single message) individually through the network. By using a sequence number and acknowledgment messages, TCP provides the source node with status of the bytes transmitted to the destination node. When data is lost during transmission, TCP can resend lost data, thereby ensuring reliable connectivity.
The related art TCP data transport process is as follows. First, the data (i.e., a file or a message) is broken into segments. To properly break up the data, the TCP must be notified of the size of the segments that the network is capable of handling, which may vary over time depending on network conditions.
Next, a header is affixed to the beginning of each segment. The header includes information related to the transmission of the segment, such as the source address, the destination address, the source port and destination port numbers, checksum information, segment length and a byte sequence number. In the header information, the checksum field contains a digest of the header and the payload, and confirms correct reception of data. The segment length field of the header specifies the number of payload bytes contained in the segment, and the sequence number of the header indicates the position of the last byte of the segment in the continuous byte stream.
After affixing the header, TCP sends the datagram to the destination and waits for an acknowledgement indicating successful transmission. The acknowledgment message may be piggybacked on an incoming segment directed to the source. If the sender (i.e., the source node) does not receive the acknowledgement message within a defined amount of time, the source node resends the unacknowledged bytes.
At the destination node, TCP receives the segment and performs a checksum test. If checksum test passes and no data bytes were lost, the destination TCP acknowledges the source TCP, as described above. Thus, the transmission process is complete.
In the related art, scaling software-based solutions for higher performance is considered a significant challenge, because the related art system usually correlates the number of bits per second to be transferred with the number of instructions per second to be processed. Accordingly, at the TCP level, it would be necessary for processors to be capable of providing performance of 10 giga instructions per second for a 10 Gbps network, resulting in a very high related art system cost.
With the advent of related art high speed network systems capable of transmission at speeds of over one gigabit per second (e.g., related art 1 Gbps and 10 Gbps systems) it would be advantageous to move the related art software based activities for TCP to a hardware environment. However, the related art does not include such a solution for TCP.
Therefore, the related art system has various problems and disadvantages. For example, but not by way of limitation, the related art system cannot produce the aforementioned desired high performance, because of the above-noted deficiencies of the related art software TCP system. As noted above, attempting such a high performance software solution would have a tremendously high cost due to its complexity.
Further, the challenges that require addressing in a multiprocessing environment for termination of transmit transport in a computer network are substantially different from the challenges of general application multiprocessing. For example, but not by way of limitation, traffic flowing over the network must be handled efficiently without impacting overall system performance.